home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1503 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: status.gen.nz!sgazza
  2. From: gazza@iconz.co.nz (Gary Elmes)
  3. Newsgroups: comp.lang.c++
  4. Subject: Heap management in .DLLs - I think I'm confused
  5. Date: Fri, 12 Jan 96 04:49:20 GMT
  6. Organization: Internet Company of New Zealand
  7. Message-ID: <4d2ppb$acv@status.gen.nz>
  8. NNTP-Posting-Host: sgazza.internet.co.nz
  9. X-Newsreader: News Xpress Version 1.0 Beta #4
  10.  
  11.  
  12. I'm using Turbo C++ v3.1 to write a .DLL file (to be called from Lotus Notes 
  13. as it happens, but that's by the by).
  14.  
  15. The Borland doco on writing DLLs is a bit skimpy. Nevertheless, I plunged in, 
  16. full of confidence, until I came across the following in some example Borland 
  17. DLL source:
  18.  
  19. >
  20. >// ObjectWindows - (C) Copyright 1992 by Borland International
  21. >
  22. ..
  23. >
  24. >int FAR PASCAL LibMain(HINSTANCE hInstance, WORD /*wDataSeg*/,
  25. >  WORD /* cbHeapSize */, LPSTR lpCmdLine)
  26. >{
  27. >    int TheStatus;
  28. >
  29. >    // Note that we can't ensure that DLLHelloLib is allocated
  30. >    // in memory owned by DLLHELLO.DLL.  Hence, it will get owned
  31. >    // by the first application that caused DLLHELLO.DLL to be
  32. >    // loaded.
  33. >    DLLHelloLib = new TModule("DLLHello", hInstance, lpCmdLine);
  34. >    TheStatus = DLLHelloLib->Status;
  35. >    if ( TheStatus != 0 )
  36. >    {
  37. >      delete DLLHelloLib;
  38. >      DLLHelloLib = NULL;
  39. >    }
  40. >    return (TheStatus == 0);
  41. >}
  42. >
  43. >int FAR PASCAL WEP ( int /*bSystemExit*/ )
  44. >{
  45. >    // don't delete DLLHelloLib here.  We haven't guaranteed that
  46. >    // DLLHelloLib points to memory owned by DLLHELLO.DLL.  It
  47. >    // will belong to the application that first caused DLLHELLO.DLL
  48. >    // to be loaded.  At the time WEP is called, that application,
  49. >    // and all of its memory, has been deleted.
  50. >    return 1;
  51. >}
  52. >
  53.  
  54. At which point I got sweaty palms.
  55.  
  56. Are the comments here trying to tell me that a .DLL doesn't have its own heap? 
  57. That all objects created via "new" are added to the calling app's heap?
  58.  
  59. I knew that .DLLs don't have their own stack, but no _heap_ ?!?!
  60.  
  61. This presumably means that I have to make sure that any objects added to the 
  62. heap when the DLL is invoked by appA are only referenced by appA, and are 
  63. deleted before appA terminates.
  64.  
  65. If this is the case, then why are Borland suggesting that we declare an OWL 
  66. TModule object (that will typically be referenced during invocations from all 
  67. calling apps) in the manner shown above - on the heap? Surely, the TModule 
  68. object will get wiped out as soon as the original calling app terminates, even 
  69. if another app is still using the .DLL.
  70.  
  71. Or have I got it all wrong? Or have Borland got it all wrong? Have I been 
  72. wasting my time putting a HEAPSIZE statement on my .DEF file all this time?
  73.  
  74.  
  75. Answers to all these questions, and more, would be very much appreciated.
  76.  
  77. TIA
  78.  
  79.  
  80. +---------- gazza @ iconz.co.nz  is  Gary Elmes, Auckland, NZ --------+
  81. |"The reasonable man adapts himself to the World, the unreasonable one|
  82. |persists in trying to adapt the World to himself. Therefore all      |
  83. |progress depends on unreasonable men." - George Bernard Shaw         |
  84. +--------------- public PGP key available on request -----------------+
  85.